Cable-anchor robot implementation using embedded CD++

We show the design and implementation of a robot controller with a unique locomotion system. We demonstrate that a discrete-event simulation based design provides a cost-effective, flexible , open workflow for modular robotic development. The robot is designed to translate against a vertical surface using cables fixed at one end that can wind on motor-controlled spools attached to the robot. This architecture was implemented first as a regressively tested simulation within CD++ then ported to Realtime CD++. Using the NXT++ interface library, a hardware implementation of the robot using Lego MindstormsTM was shown to be controllable. Categories and Descriptions B.1.2 [Control Structure Performance Analysis and Design Aids] simulation, I.2.9 [Robotics] Commercial robots and applications General Terms Design, Verification 1. Cable-Anchored Robot In applications where terrain is too difficult to traverse using legs or wheels, other forms of robot locomotion must be found. Examples include disaster areas, such as building collapse, or environmentally sensitive locations where no disturbance can be tolerated. One form of locomotion that could allow 2D and 3D locomotion involves a cable-anchored robot. Rather than wheels, a cable-anchored robot is designed to hang from two or more points fixed above and around the desired area of movement connected by cables. The ends of the cables meet at the robot and are each wrapped around motor-driven spools which the robot can rotate to let out cable or take it in. This effectively allows motion through a space or across a plane. 2. Implementation A subset of this problem using two cables and a planar surface for movement was used as a real-world design specification. The robot would translate against a vertical surface using fixed cables that can wind on motor controlled spools attached to the top of the robot (Figure 3). The attachment points to the surface (in this case instantiated as a Chalk Board) can be arbitrary, and the controller is modeled in such a way that target (x, y) Cartesian coordinates can be translated to desired cable take-up and incremental motor movements. The robot model is implemented so that the path between the current robot position and the desired position is calculated in steps of defined resolution. This allows linear robot movement to the target position regardless of the geometry of the robot and cable attachment points. Figure 1: Robot path between start and target coordinates using a path planner This controller is designed in such a way that it can be implemented using the Lego MindstormsTM robotics construction toolkit and E-CD++ . Using a bottom-up development and testing process resulted in a complex robot controller system that met desired performance goals. The flexibility of the anchor-cable locomotion system is offset by its geometric complexity; however, this was shown to be successfully addressed with a path planner that could linearize robot motions with controllable fidelity. Gabriel Wainer Carleton University Dept. of Systems and Computer Engineering 1125 Colonel By Drive, Ottawa, Canada, K1S 5B6 [email protected] Mohammad Moallemi Carleton University Dept. of Systems and Computer Engineering 1125 Colonel By Drive, Ottawa, Canada, K1S 5B6 [email protected] Jeremy Kuzub Carleton University Dept. of Systems and Computer Engineering 1125 Colonel By Drive, Ottawa, Canada, K1S 5B6 [email protected] Keith Holman Carleton University Dept. of Systems and Computer Engineering 1125 Colonel By Drive, Ottawa, Canada, K1S 5B6 [email protected] Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. SIMUTools 2009, Rome, Italy Copyright 2009 ICST, ISBN 978-963-9799-45-5 3. System Architecture A hardware implementation of the robot using Lego Mindstorms was shown to be controllable using event files. Open-loop motor control was demonstrated using the fundamentals of a simulated robot in the real world. Figure 2: Overall Model of Robot System Developing architecture for the robot controller involved breaking down the behaviour of the robot into sequential, event-driven steps. Each step had a unique function and could be more easily translated into atomic models for CD++ implementation. The Robot is the ‘top’ level coupled model (Figure 2). This represents a cable-stay robot. Each robot is composed of a Generator and Chalk Engager and two motors. This simulates how the hardware cable-stay robot would work. A robot would contain controllers, in this case a chalk engager, and two motors that communicate with Mindstorms. The Generator translates input into a format understandable by each controller. The robot can be in either passive or active state. When in passive the robot is waiting for the next event from the event file when in active the robot is handling an event from the event file or interpreting a response from the subsystem. [4] 4. Simulation Analysis The initial design was implemented in CD++ to simulate robot behaviour. The simulation initially was not completely successful, and indicated an error in the path planning algorithms was not initially detected in the atomic model tests of the Planner and Translator. Specifically, the path planner failed to generate intermediate waypoints in the special case of vertical and horizontal lines. Initial model tests were done with only diagonal lines, so cases where the slope was infinite or zero were not part of that test plan. This was easily pinpointed and corrected. This shows the value of full-up tests and simulation, not just to verify successful integration, but also to allow more opportunities to test the system in a larger data space. The greater the level of integration when an error is found, the more difficult it is to pinpoint its source; the lesson is that exhaustive unit testing is necessary, but not sufficient, as some test cases will likely be missed. This simulation also showed the value of testing algorithms in regression using two different derivation methods. Inputs and outputs should match if the system is working as expected; errors oversights are more easily spotted. The disadvantage may be in development time as a partial second set of robot control algorithms must themselves be derived, tested and debugged. The result, however, provides an additional level of confidence on the path to hardware implementation. After detecting initial problems and updating the model it behaved as expected, planning and following a physically feasible set of paths. 5. Robot Construction using Mindstorms Lego Mindstorms was chosen for its potential as an engineering education tool that is readily globally to engineering students for rapid prototyping of systems that allow reproducibility and extension. Lego kit 8527 was used to build the robot. Two servo motors were used to wind and unwind the cable spools. A third motor actuated the chalk writer. Mindstorms hardware control via NXT++ and Real-time DEVS was successful. Motor commands were properly issued and acted upon by the hardware. Real-time DEVS allowed accurate timing of motor movements; with the motors properly characterized it was possible to provide good accuracy.